Interactive voice enabled email notification and alert system and method

ABSTRACT

An interactive, voice-enabled email message notification and alert system  10  and method are disclosed. The system  10  relates to computer and communication systems and more particularly to delivery of electronic mail and other forms of electronic messages over the public switched and wireless telephone networks.

CROSS-REFERENCE TO RELATED APPLICATIONS

The application claims priority to U.S. provisional patent applicationNo. 60/427,543, filed 20 Nov. 2002 and entitled, “Interactive VoiceEnabled Email Notification and Alert” (the '543 application). Thisapplication is related to U.S. nonprovisional patent application Ser.No. 09/765,964, filed on 19 Jan. 2001 and entitled, “Method andApparatus for Implementing an Active Information Model” (the '964application), which claims priority to U.S. provisional patentapplication No. 60/176,983, filed 19 Jan. 2000 and entitled, “DatasourceHarmonizer” (the '983 application). The '543 application, the '964application, and the '983 application are hereby incorporated byreference as though fully set forth herein.

BACKGROUND OF THE INVENTION

a. Field of the Invention

This invention relates to computer and communication systems and moreparticularly to delivery of electronic mail (email) and other forms ofelectronic messages over the public switched and wireless telephonenetworks.

b. Background Art

Telephone communication and digital information exchange includingelectronic mail are two common methods of communicating, using twoseemingly independent technological disciplines. With the recentadvances in information technology and telecommunications, thecomponents for implementing systems that serve these two areas arebeginning to overlap. However, using devices from one area to serve inthe other remains a product development challenge.

The market need for a solution to provide telephone communication anddigital information exchange over a single user device can beascertained by considering the great many products that have beenintroduced and purchased over the last few years. The inherentcomplexities in the creation of a coherent solution are also evident bythe difficulty of use, the high rate of failure, and the proprietarynature of the available solutions. These complexities result indifficult-to-use, costly solutions, and product offerings that areexpensive to integrate into enterprise information systems.

Traditional approaches to enable an individual (1) to receive emailmessages and other forms of electronic notification over any telephone,(2) to redirect these notifications and associated electronic documentsto a different destination (such as a fax machine), and (3) to respondto these messages, include defining an operational domain within whichthis service is available, thereby restricting and limiting theusefulness of the solution. An operational domain may be an emaildomain, a telephone network, or a community of professionals who workfor an enterprise, or a department within an enterprise. Theseboundaries are adopted to simplify the problem of implementing acoherent system for voice communication and information delivery andaccess in systems that rely on central control or systems that areprovided by a single vendor.

BRIEF SUMMARY OF THE INVENTION

There remains a need for a system to provide telephone communication anddigital information exchange over a single user device, and it is anobject of the disclosed invention to provide a system that fulfills thisneed. The present invention is a unique aggregation of independentsoftware components that can be deployed within a single computer systemor distributed over a network of computers.

The Interactive Voice Enabled Email Notification and Alert system ofpresent invention, which is also referred to herein as IVEENA™ (IVEENAis the trademark owned by Corybant, Inc. under which the servicedescribed herein is offered to consumers), is a software system thatprovides a crossover mechanism, for a specific purpose of enabling asingle individual (1) to receive email messages and other forms ofelectronic notification over any telephone, (2) to redirect thesenotifications and associated electronic documents to a differentdestination (such as a fax machine), and (3) to respond to thesemessages immediately.

In one form, the present invention comprises a notification and alertsystem that comprises (i) a first means that receives a first message ina first format from a first message source; (ii) a second means thatprocesses the first message into a second message in a second format fortransmission to a second message destination, wherein the second formatis different from the first format, and wherein the first message sourceis different from the second message destination; and (iii) a thirdmeans for transmitting the second message to the second messagedestination. The message source and the message destination may betelephones, PDAs, computers, voicemail systems, network monitoringsystems, pagers, facsimile devices, satellite telephones, radios, orother devices that are capable of receiving electronic messages. Thefirst messages may be a digital message, for example, an email message,a HTTP stream, a network alert condition, or some other form of networkmessage based upon TCP/IP and compatible protocols. The second messagemay be, for example, a digital voice message. Alternatively, the firstmessage may be a digital voice command, and the second message may be anelectronic notification (e.g., a digital email message or a databaserecord).

In one form, the invention may be configured to accepts userpreferences. These preferences may include, for example, (a) scheduling(e.g., when the user desired to be contacted), (b) whether the system ison or off (i.e., the user may decide to completely disable thenotification and alert system temporarily), (c) the second messagedestination (i.e., the user may freely designate where that user wantsto receive notifications and alerts), (d) message selection andfiltering criteria (i.e., the user may provide and update the parametersused by the system when determining when a notification or alert isdesirable), and (e) an option to temporarily suspend or interruptscheduled calling (i.e., this is an alternative to completely shuttingthe system down and then having to re-activate the system later). Theuser may make these preferences known to the system via multiplesources, including any telephone or a browser connected to a globalcomputer networks.

The system of the present invention may have a public side and a privateside. The public side may be connected to at least one of (i) a globalcomputer network (e.g., the Internet), (ii) public switched telephonenetworks via a voice service, and (iii) World Wide Web servicesincluding Web application servers and Web servers. The private side ofthe system may maintain information about the first and second messagesuntil application requirements for these first and second messages aresatisfied.

In yet another form, the invention comprises a notification and alertsystem that tracks user and action data for configuration management,policy enforcement, and integration with multiple level billing,accounting, and auditing systems. In this form, the notification andalert system comprises (i) an accepting means that accepts a firstmessage in a first format from a first message source, wherein the firstmessage comprises user and action data; (ii) a converting means thatconverts the first message into a second message in a second format fordelivery to a second message destination, wherein the second format isdifferent from the first format, and wherein the first message source isdifferent from the second message destination; (iii) a delivery meansfor delivering the second message to the second message destination; and(iv) a tracking means for tracking the user and action data.

In still another form, the invention comprises a user-centric system fortransforming and exchanging information elements. In this form, thesystem comprising (i) one computer or a plurality of networkedcomputers, and (ii) a software engine running on that computer. If aplurality of networked computer are used, the computers may be runningdifferent operating systems. The software engine comprises (i) a firstmeans for identifying an information source within the user-centricsystem and for identifying information elements from the informationsources; (ii) a second means for transforming at least one of theidentified information elements, according to a first plurality oftranslation rules, into at least one transformed information element;(iii) a third means for identifying an information destination withinthe user-centric system, wherein the third means accepts auser-selectable information destination; and (iv) a fourth means forexchanging the at least one transformed information element between theinformation source and the information destination.

The invention also comprises a method of notifying and alerting at leastone system user of the arrival of an electronic notification that hasbeen selected based upon a specified criteria. This method comprisingthe steps of (i) establishing access to a computer network; (ii)receiving via the computer network a first message in a first formatfrom a first message source; (iii) processing the first message into asecond message in a second format for transmission to a second messagedestination, wherein the second format is different from the firstformat, and wherein the first message source is different from thesecond message destination; and (iv) transmitting the second message tothe second message destination. The “electronic notification” may be,for example, an email message, and the receiving step may furthercomprise receiving the email message from the first message source.

In yet another form, the present invention comprises a method ofnotifying and alerting a system user of the arrival of a selectedelectronic notification selected based upon a user-specified criteria.The method comprises the steps of (i) establishing access to a computernetwork; (ii) receiving via the computer network a first message in afirst format from a first message source; (iii) processing the firstmessage into a second message in a second format for transmission to asecond message destination, wherein the second format is different fromthe first format, and wherein the first message source is different fromthe second message destination; (iv) transmitting the second message tothe second message destination; (v) receiving via the computer network athird message in a third format from a third message source, wherein thethird message source is different from the first message source; (vi)processing the third message into a fourth message in the second formatfor transmission to the second message destination; and (vii)transmitting the fourth message to the second message destination.

The foregoing and other aspects, features, details, utilities, andadvantages of the present invention will be apparent from reading thefollowing description and claims, and from reviewing the accompanyingdrawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an schematic representation of one possible implementation ofthe present invention.

FIGS. 2A-2I depict the various symbols used in FIGS. 3-6.

FIG. 3 outlines the process of activating an IVEENA Application.

FIG. 4 outlines the process of preparing an Alert and activating aService.

FIG. 5 outlines the process of authenticating the Service request anddelivering the appropriate information to the Service.

FIG. 6 outlines the process of storing the user's response and thetransaction record.

DETAILED DESCRIPTION OF THE INVENTION

IVEENA is a widely-distributed software system 10 implemented by aunique combination of commercially available software components thatwork independently, including the following:

-   -   Post Office Protocol Version 3 (POP3) (see Appendix A, item 1);    -   Simple Mail Transfer Protocol (SMTP) (id. at item 2);    -   Structured Query Language SQL (id. at item 3);    -   Voice eXtensible Markup Language (VoiceXML) (id. at item 4);    -   JavaBean™ (id. at item 5);    -   Servlets (id. at item 6);    -   Component-Based Distributed Applications (id. at item 7);    -   Unified Modeling Language (UML) (id. at item 8);    -   Extensible Markup Language (XML) (id. at item 14); and    -   Simple Object Access Protocol (SOAP) (id. at item 15).

IVEENA can be implemented to work on a single computer or on acollection of computers that are connected through one or more public orprivate networks. FIG. 1 is a schematic representation of one possibleimplementation of the present invention. In this figure, the IVEENAsystem 10 enables a user 12 to receive, for example, email messages 14via a telephone 16. For example, the system 10 enables the user 12 tohave an email message 14 that meets certain user-defined parameterstrigger a telephone call to the user 12 during which software componentsconvert the textual email message to an oral message that is read to theuser over the telephone 16 by a speech synthesizer.

After listening to the email message 14, the user 12 may forward theemail message and/or a document that was attached to the email messageto, for example, a facsimile device 18 or other electronic communicationor data processing device 20 (e.g., a network monitoring system, apersonal digital assistant (PDA), or a pager), or to another individual.Alternatively, the user 12 may respond to the email message orally, andthe system 10 is able to forward the user's oral reply to the sender ofthe original email message. If the user elects to forward the originalemail message to another individual, the user may provide an oralmessage to accompany the original email message as forwarded. The system10 may be instructed to convert the user's oral response or forwardingmessage into text to accompany the original message that is beingforwarded. The feature labeled “Internet” 22 in FIG. 1 may comprise thevarious software components, servers and other computers, workstations,terminals, networks, databases, and other data sources employed by thesystem 10, as described further below. As represented by the connectionlines 24 in FIG. 1, the system 10 enables communication between andamong all of the devices 14, 16, 18, 20.

Description of the Building Blocks of IVEENA Depicted in FIGS. 2A-21

The IVEENA system 10 (FIG. 1) performs its functions by activatingmultiple instances of a relatively small set of software components,including the following:

-   -   Communication Server    -   Service    -   Database    -   Session Object    -   Message    -   Queue    -   Message Triggered Object (MTO)    -   Network Communication Object (NCO)    -   Scheduler        These software components or elements or “building blocks” of        the IVEENA system 10 are depicted in FIGS. 2A-2I. In particular,        FIGS. 2A-21 depict nine different symbols that are used in FIGS.        3-6 to represent system building blocks used by the IVEENA        system 10 as it performs various functions. The symbols signify        system components that implement specific system functions and        have a predefined behavior and predefined interfacing rules.

FIG. 2A depicts a symbol 200 for a Communication Server. A CommunicationServer is a software system or program that can receive electronicinformation and store that information. A Communication Server that isused by IVEENA can be configured to select the messages that it willprocess based upon a predefined set of rules (a selector or a filter).In the existing embodiments of the invention, IVEENA uses servers thatimplement two common communication protocols, namely POP3 and SMTP. TheCommunication Server operates within the context of wireless and wiredLocal Area Networks (LANs), Wide Area Networks (WANs), Public SwitchedTelephone Networks (PSTNs), and Public Internet. It can interface tointer-carrier messaging methodologies such as Short Messaging System(SMS) and can accommodate a range of standard communication protocolsincluding SNMP (see Appendix A, item 10), HTTP (id. at item 11), TCP(id. at item 12), and UDP (id. at item 13).

FIG. 2B depicts a symbol 202 for a Service. The IVEENA system has theability to use Services that are available over the public (or private)networks as an integral part of the application that it implements. Inthe current embodiment of the invention, IVEENA uses the standardindustry protocols such as XML, SOAP, and popular vendor offerings suchas J2EE (see Appendix A, item 16) for external communication. The IVEENAproduct that is commercially offered uses a Voice Service (id. at item4) to deliver voice messages over telephone networks and enables usersto respond via voice or tone selection, commercially available Internetfacsimile services, and a number of email message services.

FIG. 2C depicts a symbol 204 for a Database. A Database is one or moresecure databases (see Appendix A, item 3) that contain the persistentinformation for the IVEENA system. IVEENA allows for the case where theDatabase is a part of the enterprise information system and its accessto the database may be, at a basic level, a query of one of thefollowing forms:

-   -   SELECT*FROM table WHERE ‘a’=‘a1’ AND ‘b’=‘b1’ . . .    -   and    -   INSERT INTO table WHERE ‘a’=‘a1’ AND ‘b’=‘b1’ . . .

FIG. 2D depicts a symbol 206 for a Session Object. A Session object is astateless software elements that is administered systematically and isavailable to the distributed elements of the IVEENA system. Theseobjects provide access to the Database. This characteristic of thesystem makes it possible to integrate IVEENA into existing informationsystems rapidly and allows the system administration of theseinformation systems to continue independently of the IVEENA system. Forexample, an enterprise may move the physical location of a databasesystem or move certain parts of the database to another system. In thecurrent embodiment of the invention, these Session Objects areimplemented as EJB™ Session Beans (see Appendix A, items 5 & 7).

FIG. 2E depicts a symbol 208 for a Message. A Message is a unit ofinformation that is transmitted between two elements of the IVEENAsystem. In the current implementation, a Message is implemented as atable of name-value pairs and may include other Messages as an element.

FIG. 2F depicts a symbol 210 for a Queue. A Queue is a mechanism forstoring and dispensing Messages. This mechanism is used by the elementsof IVEENA and is not accessible externally. Communications between theelements of IVEENA are atomic at each transaction. Elements of theIVEENA system do not share any information that is not “passed” throughthis messaging mechanism. Consequently, the Queue mechanism can operateover a network, thereby enabling IVEENA to operate reliably and securelyover multiple computer systems, public networks, or private networks.This capability is important for integrating IVEENA into existingenvironments as well as enabling an enterprise that uses IVEENA tochange elements of its information system incrementally over time. AQueue is a mechanism to pass Messages between the elements of IVEENA.IVEENA does not depend on its Queues to maintain their state in case ofa system failure. Instead the operating protocols within IVEENA make itpossible to restore the state of the system transactions from theDatabase.

FIG. 2G depicts a symbol 212 for a Message Triggered Object (MTO). MTOsare state-full software elements (objects) that are used in conjunctionwith a Queue and perform the functions that are associated with thatQueue. When a Message is sent to a Queue that serves a function, andwhen system resources are available, a MTO is created to process thatMessage. The overall operation logic of each application is defined bydirecting Messages to the appropriate Queues. During the process ofcreating an application, the application developers identify basicoperations of that application and if needed create the appropriateMTOs. There are certain conditions where a Message may reflect a statethat extends beyond the execution state of an MTO. For example, in thecase where IVEENA is used to deliver email messages via telephone, whentwo email messages for the same user are received a short time intervalapart, it will trigger two independent chains of events with unpleasantresults for the user. The design of the IVEENA system incorporates anabstract concept of “Application Context” to enable developers to managethese situations at the level of application design. IVEENA enforcesthis abstract concept through a convention. Information reflecting thehigh-level concepts, such as the user state information, is storedindependently as database records. Although the process of invocation ofan MTO is automatic, each MTO, upon activation, may check the user stateand suspend operation if there is another MTO operating on behalf ofthat transaction. In the case of the example above, only one MTO isresponsible for, handling email messages within an activation period. Inthe current embodiment of the invention, Message Triggered Objects areimplemented as EJB Message Driven Beans (see Appendix A, items 5 & 7).

FIG. 2H depicts a symbol 214 for a Network Communication Object (NCO).An NCO is a network-accessible software module that implements astandard network communication protocol for exchanging information withanother network device. A number of such components are used in theindustry, and many such components can serve this function for IVEENA.For its existing embodiments, IVEENA uses JAVA™ Servlet objects (seeAppendix A, item 6). These modules are visible from a public network andprovide access into and out of the IVEENA system.

FIG. 2I depicts a symbol 216 for a Scheduler. A Scheduler is a programwithin IVEENA that is activated periodically and serves as a taskscheduler that monitors pending actions and reactivates system elements.

Each computer that supports the operation of IVEENA hosts one or more ofeach of these software components or building blocks. IVEENA is flexibleand scalable so that it can easily integrate into existing environmentsand can accommodate changes in those environments over time. To achievethis flexibility and scalability, these building blocks meet thefollowing criteria:

Each building block performs a complete task.

Each building block receives all of the information that it needs toperforms its tasks from its input and delivers all of the informationthat it creates in its processing, i.e., there is no need for onebuilding block to “look inside” another building block for anyinformation.

Each building block is constructed from one or more software componentsthat are commonly used in the industry or offered as a service or aproduct by multiple suppliers.

Each building block supports a communication protocol that is propagatedby national or international standards group.

Steps Demonstrated in FIG. 3

FIGS. 3-6 trace the flow of information through the system 10 in foursample scenarios. In cases where an example may help clarify a topic,the following description uses an event, whereby an email messagecontaining a destination and a specific textual content is received byIVEENA, and is to be delivered to an individual over a telephone as avoice message. We refer to this example as “mailreader.”

Referring first to FIG. 3, the process of activating an IVEENA“Application” is described next An “Application” is a function that theIVEENA system 10 performs for the user 12 or the enterprise. Such aprocess may be initiated through a direct command that is relayedthrough an NCO, by a Client agent within IVEENA that is instantiated inresponse to a scheduled action, or by an event that is received througha Communication Server, such as receiving an email message from a mailserver.

In FIG. 3, the Communication Server 300 receives an electronic message302. The Communication Server 300 applies its selection criteria and, ifthis electronic message passes this criteria, the Communication Server300 sends a Message 304 that activates the “Alert” NCO 306. For example,in the case where IVEENA is serving as a “mailreader,” an email messageis received by an email message server (a POP3 server) that isassociated with IVEENA and is addressed to an IVEENA user. The user mayhave specified a selection criterion, such as “I will accept only emailmessages from domain abcd.com”. The Communication Server 300 selects theemail message based upon the selection criteria and triggers the AlertNCO 306. The “Alert” NCO 306 creates a Message 308 containing a user'sexternal identification and posts it with the “Client” queue 310.

The Scheduler 312 searches the “to-do” records in the Database 314, asrepresented by the Session Object 316, to find an event record whoseexecution time is less than the current time, i.e., to find any pendingtasks that needs to be performed at this time. An example of such anevent is an email message that failed to be delivered in earlierattempts because the service or the recipient was unavailable. When apending event is ready for execution, the Scheduler 312 creates aMessage 318 and posts it with the “Client” queue 310.

A “Client” MTO 320 retrieves the Message 318 posted with the “Client”queue 310 and retrieves “user records” and “user state rules” from thedatabase 322, as represented by the Session Object 324. The “userrecords” contain information about a user such as the user's activetelephone number or the time of day when the user may wish to be called.The “user state rules” signify the relationship of the user to IVEENA,for example, another task is in the process of calling the user on theirtelephone. At this point, the user state record is updated and anotherApplication MTO that may be concurrently processing related informationcan use such state information to determine the proper course of action.

The “Client” MTO 320 creates a Message 326 containing the ApplicationContext and posts it to an Application queue 328 that relates to theappropriate Application as determined by the user record and the type ofincoming request. The Application Context is the collection of user andsystem information that define the context within which an applicationcan perform a service for or on behalf of the user. For example, in thecase of the “mailreader” application, the Application Context includessuch information as the user's phone number and language and deliverypreferences, and the Client MTO 320 posts the Message 326 to the“mailreader” Queue 328.

A Command Portal NCO 330 may also post an Application Context to theApplication queue 328 via a message 332. The Command Portal NCO 330 isfor external systems to activate an IVEENA application. For example, aCommand Portal is provided as an interface to an enterprise orthird-party Interactive Voice Response service. This portal enablesusers to call in to the IVEENA system to check for their email messages,to request that a stored message be sent to a fax machine, or to send avoice message to a group of users as a part of an email message.

The Application queue 328 instantiates an Application MTO 334corresponding to this Application. The Application MTO 334 implementsthe Application logic. In the case of “mailreader,” the email messagefor this user is retrieved from the Communication Server 300 via amessage 336.

In most cases, the logic of the Application MTO 334 will includecreation of an Alert record that is stored in a database 338 via asession object 340. In the case of “mailreader,” the Alert recordcontains the relevant elements of a MIME encoded message (see AppendixA, item 17) such as email message header information, the text containedin the body of the email message, and attachments.

The Application Context includes policy information that governs theapplication. For example, the user may have a preference for receivingtelephone calls at certain times of the day. The Application MTO 334creates the appropriate “to-do” records for such activities as delayedexecution, other activities, or to safeguard against system failures.Those “to-do” records are stored in the database 314 via a SessionObject 342.

Steps Demonstrated in FIG. 4

Referring next to FIG. 4, the process of preparing an Alert andactivating a Service (such as a service to convert a text message tovoice and to deliver it via telephone, or a service to deliver afacsimile) is described next.

The Application MTO 400, which is associated with the Application Queue401 implements the operational logic or functions that are performed byIVEENA on behalf of or for the user. When such activity is considered atransaction, the Application MTO 400 creates a user Transaction recordin a database 402, as represented by the Session Object 404.

Next, via a message 406, the Application MTO 400 invokes one or moreService Portal NCOs 408. As depicted in FIG. 4, the Service Portal NCO408 implements, via a message 409, the protocol to start a Service 410.Different protocols may be appropriate for different services anddifferent vendors supplying similar services. For example, starting aService to make a telephone call and deliver a voice message would startwith authenticating a communication session and directing that Serviceto the proper location to retrieve the program containing the voicemessage. One provider of service that delivers a facsimile requires anemail message with the appropriate content and headers, whereas adifferent provider may support a HTTP interface (see Appendix A, item11).

The Service Portal NCO 408 retrieves the Service Configuration recordfor the Service from a database 411 via a Session Object 412, andcreates the appropriate request protocol. The Service Portal NCO 408 mayaccess or modify the Action records in a database 414 via a SessionObject 416 at this point in the process based upon the requirements ofthe service request protocol.

The Application MTO 400 may post the Application Context to the AlertContext queue 418 via a message 420. An Alert Context MTO 422 isassociated with the Alert Context queue 418, and is a mechanism forconverting, via a Session Object 424, an Action record in the database414 into an Alert that can be delivered to users. By providing for anabstract definition of an Alert that is independent of a specificapplication, IVEENA separates the process of message delivery from thepolicies that govern message delivery for a given organization or withinthe context of a given application.

The Alert Context MTO 422 implements the logic associated with an Alertas specified by the Application Context and creates an Alert Message426. This may be a single email message that is converted to a menu thatdelivers the message to the user and requests a response, or it may bethe next message in a series of messages that are to be delivered tomultiple users according to a distribution scheme specified by theapplication. The processed Alert Message 426 is sent to an Alert queue428.

As represented by the message 430, the Service Portal 408 may alsocreate an Alert record for later delivery to a Service. A Servicegenerally uses this interface for status update, where the ApplicationContext is part of the request, for example, when the Service isprocessing a transaction and is requesting “the rest of” a data system.

Steps Demonstrated in FIG. 5

Referring next to FIG. 5, the process of authenticating the Servicerequest and delivering the appropriate information to the Service, suchas delivering voice menus or retrieving the alert for delivery by thevoice service, is described next.

The IVEENA service interface provides for both “push” and “pull” modelsof interfacing to a network service. For example in the case of the“mailreader,” the system may post a request to a Service to place atelephone call to a user (push), or a user may call the Service to findout if they have messages, whereby the Service posts a request to IVEENA(pull). IVEENA and a Service may use both of these models whiledelivering a single service to the user.

A Service communication protocol may require a service 500 to requestinformation about its basic operational parameters. This request isrepresented in FIG. 5 by message 502. A Menu Portal 504 in IVEENA is amechanism, specific to a service class, to accommodate this requirement.

The Menu Portal NCO 504 provides, via a Session Object 506, theinformation based on the parameters in the Service Configuration recordsin a Database 508. The Service Configuration records may be specific toa service, an organization, or user group, or to a specific user serviceclass, to accommodate this requirement.

As represented by the message 510, an Authentication Portal NCO 512provides a mechanism to validate a service state (such as a user's nameand password). In general, the information from this portal is a timesensitive token that can be used to access or decrypt information thatis delivered to the Service.

The Authentication Portal NCO 512 provides, via Session Object 514,authentication information based upon information in the User records ina Database 516. This capability enables an enterprise to enforce accesspolicies in a structure that is independent of the actual flow of datawithin an information system.

Once validated, the Service 500 may request, via message 518, thecontent of the request from the Alert portal NCO 520. This informationis usually requested by providing an encoded token such as a transactionID that is used by the Alert Portal NCO 520 to fetch, via message 522,the proper information from an Alert queue 524.

Steps Demonstrated in FIG. 6

The IVEENA service handling model includes a mechanism for acceptingintermediate as well as final responses from a Service 600. In certaincases, this information can serve to report on the state of atransaction or a group of transactions. In other cases, IVEENA will usethis information to determine the flow of information within a singletransaction.

The Service 600 posts a Message 602 to a Transaction Portal NCO 604. Inthe IVEENA Service model, multiple Transaction Portal NCOs may serve aService, implementing, along with the service menu outlined in themessage 502 (FIG. 5) the logic of processing a service transaction.

The Transaction Portal NCO 604 may respond to the Service 600 byproviding additional service parameters or alterations to the Serviceflow via a message 606. The Transaction Portal NCO 604 may access, via aSession Object 608, the Alert records in a Database 610 when preparingthis response. The Transaction Portal NCO 604 posts a Message 612 to theTransaction Queue 614 associated with this Service 600 or with theIVEENA application that is in progress.

A Transaction MTO 616 associated with the Transaction Queue 614 updatesthe Alert records in the database 610 via a Session Object 618. TheTransaction MTO 616 associated with the Transaction Queue 614 updatesthe Transaction records in a database 620 via a Session Object 622.

Unique aspects of the invention include, but are not limited to, thecombination of the above-mentioned components, the flow of theinformation as described above, the processing of messages that enablethe system to process multiple requests concurrently and to recover fromerror conditions, and the support for implementing enterprise andservice policies by identifying system and user behavior during thecourse of a transaction.

Although a number of embodiments of this invention have been describedabove with a certain degree of particularity, those skilled in the artcould make numerous alterations to the disclosed embodiments withoutdeparting from the spirit or scope of this invention. For example, it iswithin the scope of the invention to use the IVEENA system to processtransactions and any activity that involves the use of externalresources in a way that simplifies integration with multiple back-endreporting and billing systems, including multi-level seller and resellerstructures. It is intended that all matter contained in the abovedescription or shown in the accompanying drawings shall be interpretedas illustrative only and not limiting. Changes in detail or structuremay be made without departing from the spirit of the invention asdefined in the appended claims.

The following publicly-available references are hereby incorporated byreference as though fully set forth herein:

1. Internet Engineering Taskforce, Post Office Protocol Version 3(POP3), Internet Engineering Taskforce Request For Comments 1939(ietf/rfc-1939) May 1996.

2. Internet Engineering Taskforce, Simple Mail Transfer Protocol (SMTP),Internet Engineering Taskforce Request For Comments 821 (ietf/rfc-821)August 1982.

3. ISO/IEC 9075:1992, Database Language SQL—Jul. 30, 1992.

4. Voice XML forum, Voice extensible Markup Language (VoiceXML)Specification 1.0, March 2000. Published by Voice XML forum, a programof IEEE Industry Standards and Technology Organization (IEEE-ISTO).

5. Sun MicroSystems, Inc., JavaBean™ specification version 1.01A August1997, published by Sun MicroSystems, Inc. Graham Hamilton (Editor).

6. Dustin R. Callaway, Inside Servlets, Server Side Programming for theJava™ platform, 3^(rd) Printing November 1999, Published by AddisonWesley Longman Inc. ISBN 0-201-37963-5.

7. Tom Valesky, Enterprise JavaBeans™ Developing Component-BasedDistributed Applications 4^(th) Printing November 1999, Published byAddison Wesley Longman Inc. ISBN 0-201-60446-9.

8. Jim Conallen Building Web Applications with UML 3^(rd) Printing March2000, Published by Addison Wesley Longman Inc. ISBN 0-201-61577-0.

9. Qusay H. Mahmoud Distributed Programming with Java ©2000, Publishedby Manning Publication Co. ISBN 1-8847777-65-1.

10. Network Working Group, Simple Network Management Protocol (SNMP)Request For Comments 1157 (ietf/rfc-1157) May 1990.

11. Network Working Group, Hypertext Transfer Protocol—HTTP/1.1 RequestFor Comments 2616 (W3c/rfc-2616) May 1990.

12. Defense Advanced Project Agency Transmission Control Protocol (TCP)DARPA Internet Program Protocol Specification ietf/rfc/793 September1981.

13. J. Postel, ISI, User Datagram Protocol (UDP) rfc/0768 August 1980.

14. Extensible Markup Language (XML) 1.0 W3C Recommendation 6 Oct. 2000http://www.w3.org/TR/2000/REC-xml-20001006.

15. Simple Object Access Protocol (SOAP) 1.1 W3C Note May 8, 2000,http://www.w3.org/TR/2000/NOTE-SOAP-20000508.

16. Sun MicroSystems, Inc., Java™ 2 Platform Enterprise EditionSpecification version 1.4 Jul. 12, 2002, Bill Shannon Published by SumMicro Systems, Inc.

17. RFC 1341—MIME (Multipurpose Internet Mail Extensions): Mechanismsfor Specifying and Describing the Format of Internet Message Bodies.

1. A distributed notification system for delivering selectedcommunications in real time to a recipient in an alternate communicationformat and/or via an alternate communication network, the systemcomprising; a communication server for receiving and storing an initialcommunication in a first format intended for a first destination over afirst communication network; a selection module that screens saidinitial communication pursuant to a first set of rules defined by therecipient to determine whether said initial communication should beidentified as a selected communication for alternate delivery; a rulesdatabase that stores recipient state information and a second set ofrules, which are at least in part defined by the recipient, forapplication to said selected communication wherein said second set ofrules, in conjunction with said recipient state information, determinesaid alternate communication format and/or said alternate communicationnetwork for delivery of said selected communication; a rules module thatqueries said rules database for said recipient state information andsaid second set of rules and instantiates an instruction applicationbased on said recipient state information and said second set of rulesto direct further processing of said selected communication; a servicemodule that is invoked by said instruction application and that convertssaid selected communication from said first format to a second format;and a delivery module that automatically delivers said selectedcommunication in said second format to a second destination directed bythe instruction application according to said recipient stateinformation and said second set of rules.
 2. The system of claim 1,wherein said delivery module delivers said selected communication insaid second format to said second destination over a secondcommunication network.
 3. The system of claim 1, wherein said servicemodule further comprises a third party application service invokedtemporarily by said instruction application to become part of thesystem, wherein said third party application service is connected withthe communication server via a network; said third party applicationservice receives said selected communication from said communicationserver via said network; said third party application service convertssaid selected communication from said first format to a second format;and said third party application service further functions as saiddelivery module and delivers said selected communication in said secondformat to said second destination pursuant to said recipient stateinformation and said second set of rules.
 4. The system of claim 3 funher comprising a command interface accessible by said third partyservice application for instantiating an additional instructionapplication.
 5. The system of claim 1 further comprising a schedulingmodule and an event database that stores event records, wherein saidscheduling module queries said event database and independentlyinstantiates said instruction application upon reaching an activationtime for each of said event records.
 6. The system of claim 1 furthercomprising a command interface accessible via a network through whichthe recipient of said selected message can amend at least one of saidfirst set of rules and said second set of rules.
 7. The system of claim1 further comprising a command interface accessible via a networkthrough which the recipient of said selected message can independentlyinstantiate said instruction application.
 8. The system of claim 1further comprising a command interface accessible via a network throughwhich an enterprise can amend at least one of said first set of rulesand said second set of rules applicable to multiple recipientsassociated with the enterprise.
 9. A method for providing selectmessages to a recipient in real time in an alternate communicationformat and/or via an alternate communication network, the methodcomprising; receiving an initial communication in a first formatintended for a first destination at a communication server via a firstcommunication network; screening said initial communication pursuant toa first set of rules defined, at least in part, by the recipient, todetermine whether said initial communication should be identified as aselected communication for alternate delivery; temporarily storing saidselected communication at said communication server; sending an alertmessage to a notification system to initiate a process for delivery ofsaid selected communication in a second format; querying a rulesdatabase for recipient state information and a second set of rules forapplication to said selected communication, wherein said second set ofrules, in conjunction with said recipient state information, determinesaid alternate communication format, an alternate destination, and/orsaid alternate communication network for delivery of said selectedcommunication; converting said selected communication from said firstformat to a second format based upon said recipient state informationand said second set of rules; and automatically delivering said selectedcommunication in said second format to said alternate destination. 10.The method of claim 9, wherein said step of delivering further comprisesdelivering said selected communication in said second format over saidalternate communication network.
 11. The method of claim 9, wherein saidstep of converting further comprises: temporarily invoking a third partyapplication service to convert said selected communication from saidfirst format to said second format; and transmitting said selectedcommunication from said communication server to said third partyapplication service via a network; wherein said step of delivering isperformed by said third party application service.